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WELCOME TO MODULE 2: 
DEFINING AND ATTACKING 
THE PROBLEM 


Every day, we experience the challenge of solving problems. Often, 
though, we take for granted the logical processes that most of us go 
through to solve everyday problems. While many problems are relatively 
simple and do not require a formalized approach to problem solving, a 
complex problem requires a logical strategy -- one that begins with a 
definition of the problem itself. 


In this module, you will be introduced to a strategy that will be 
useful in your programming work. You'll begin by learning how to formulate 
the basic problem statement. Opportunities will be provided to rearrange this 
problem statement into the actual tasks to be performed by the computer. 


The interactive diskette included with this module contains two 
incomplete programs: a checkbook register, and a phone book/mail list 
program. You will have an opportunity to design a visual display to 
accompany each of these programs. 


For your review, we have also included a solution to the loan 
amortization program that you worked with in Module 1. You will be able 
to check your results against the configuration contained on the diskette, 
which illustrates one possible arrangement for performing all of the 
requirements stated in the first module. 


After you have completed this module, you'll be ready for the next 
module: How to Design the Solution and Arrange It Logically. Here, you'll 
investigate logical ways to sequence tasks, and you'll diagram a solution 
to the problem you have previously identified. 


We now invite you to learn more about defining and attacking the 
problem. 


Sincerely yours, 


Kennet )- Began 


Kenneth J. Bigelow 
Project Engineer 
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CONTEMPORARY 
PROGRAMMING 
AND SOFTWARE 
DESIGN SERIES 


WELCOME to Module 2 of McGraw-Hill’s Con- 


temporary Programming and Software Design Series. In 
this module, you will continue your study of the process 
of program design and development. 

The disk provided with this module is intended for the 
Commodore 64 and 128 computers. It is formatted in 
C64 format, and can be used by the 64 and the 128 in 64 
mode. Unless otherwise specified, all programs on this 
disk are written in BASIC. 

Although it is not strictly necessary, we suggest that 
you put a write-protect tab on the enclosed disk, and 
make a backup copy of this disk. Use your backup copy 
when working with this module. This will enable you to 
copy the original disk again and continue working, in case 
your working disk — the backup copy — should become 
damaged or scrambled by accident. The BACKUP pro- 
gram that we supplied on the Module 1 Program Disk will 
perform this task readily, and will format the destination 
disk if desired. 

Make as many backup copies as you need to for your 
own use. However, please remember that, unless other- 
wise specified, all programs on this disk are copyrighted 
(C) by McGraw-Hill. It is not legal for you to give or sell 
copies of the disk or the manual to anyone else. 

The program listings in this manual are identical with 
the programs on disk to which they refer. However, you 
should still LIST the programs as indicated in the text to 
gain the maximum possible benefit from this module. 

All of the example programs on this disk are written in 
BASIC. To run them, turn on your peripheral devices 
and your computer (in that order), and then insert your 
program disk into drive 8. Remember, NEVER turn ona 


computer or peripheral device while a disk is in the drive, 
no matter what the manual or anyone else may say. Even 
one stray impulse at this step can scramble crucial data 
on your disk and make it useless. Be safe, not sorry. 

With your equipment turned on and the disk in drive 8, 
you can start Module 2 with the commands: 


LOAD “WELCOME”, 8<return> 
RUN<return> 


Then, when the computer directs you to turn to your 
Learning Guide, begin with the Introduction. Your 
adventure into the realm of programming is about to 
continue. 

Your Program Disk for Module 1 included some extra 
programs: DEPRECIATION, KWIK LOAD, and BACK- 
UP. These programs are in the public domain, and may 
be freely shared with others who are interested. DE- 
PRECIATION is useful for income tax purposes and for 
financial applications. It calculates the depreciation rates 
of various equipment according to different methods. 
This allows you to use the most favorable method for 
figuring the depreciation of equipment you may use ina 
home business. 

KWIK LOAD is useful for speeding up disk accesses 
for the C64. It does this by disabling the video display 
during disk operations. This eliminates interrupts used to 
maintain the video display, so disk operations are not 
periodically stopped for video updates. However, it also 
means that the display will be blanked during disk opera- 
tions. Once you have run KWIK LOAD, you can only end 
the program by turning your computer off and then on 
again. We suggest that you try disk operations both 
ways, and decide for yourself whether or not to use 
KWIK LOAD. 

BACKUP is designed to duplicate a C64 disk. It first 
examines the source disk to determine what parts of the 
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disk are actually in use. It then reads into memory as 
many of the active sectors as possible, and requests the 
destination disk. If requested, BACKUP will format the 
destination disk first. Then, it writes the active data from 
the source disk onto the destination disk in the same 
locations. If it is necessary to swap disks again, BACKUP 
will prompt you to do so. 

The enclosed program disk adds two more programs 
to your library: CALENDAR and INVESTMENTS. These 
are also in the public domain and may be freely shared. 
To see them in operation, LOAD and RUN them. Each 
program includes all necessary instructions. 

When you are ready, go ahead with Module 2, and 
once again, WELCOME. 
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MODULE 2 


DEFINING AND ATTACKING THE PROBLEM 


In your first module, we took a general look at the programming 
process and saw examples of the main stages in this process. We also 
looked in detail at a specific program (the LOAN program), and made a 
number of corrections and improvements in its operation. 

However, we did not look at the details of programming. Each of the 
main stages of programming involves a certain amount of work and 
some careful considerations. Each stage carries logically to the next until 
the entire job is done. 

In this module, we will go through the first part of the programming 
process for two program examples. As we do so, we will also examine 
working program segments that correspond to various parts of the 
programming process that we are studying. Finally, we will look at an 
expanded version of the LOAN program from Module 1, and then start 
working with some additional practical programs. 

It has been said that the job that’s never started is the one that takes 
longest to finish. So, let’s get started and see just how we begin any 
programming task. 
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NOTES: 
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If your computer is available at this time, turn it on and 
insert your program disk in drive 8. Then, type in the 
commands: 
LOAD “WELCOME”, 8<return> 
RUN<return> 


When the program ends, return to this point. In case 
your computer is not available right now, Figures 1-1 and 
1-2 show the primary displays generated by your 
computer. 

Before you can tell the computer how to do 
something, you must know how to do it yourself. 
You won't actually have to solve the problem or 
manipulate the data (that’s what the computer will 
do), but you will have to know how to do it so that 
you can specify it for the computer. But by the same 
token, you can’t solve any problem until you know 
what that problem is. If you can’t state the problem, 
you'll never be able to find the solution. So the first 
step in designing a computer program, just as it 
would be for solving a problem by hand, is to deter- 
mine just what the problem is. 
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Sector 1: The Problem Statement 


Consider the typical schoolroom problem: John is 
three years older than Mary, and their ages total 17 
years. How old are they? 

This kind of word problem appears often, in many 
walks of life. Of course, this particular word problem 
is deliberately simplified to the point that anyone ex- 
perienced with word problems can solve it mentally, 
without recourse to pencil and paper. (In this case, of 
course, John is 10 and Mary is 7.) Nevertheless, 
most real-life problems are initially stated in words, 
just like this one. 

The first requirement in solving a word problem is 
to sort through it to determine exactly what is wanted 
as the final answer. Thus, before we can solve the 
problem, we must know what information will be re- 
quired as the final answer. We don’t know the final 
answer yet, but we do have to know what we will be 
looking for to produce that final answer. From then 
on, we can keep working toward that final goal. In 
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Defining | Defining 
the the 
Problem Solution 


Debugging 
the 
Program 


exactly the same way, the very first step in writing a 
computer program to solve a problem is to determine 
exactly what that problem is. Only then can we start 
looking at ways to solve that problem. 

In many classrooms, the teacher will require 
students to organize a word problem into “categories” 
such as GIVEN:, TO FIND:, USE PROCEDURE:, 
etc. The idea here is to require the student to break 
the problem down into logical steps, and then to 
delineate the logical solution procedure. The actual 
solution is then a matter of “turning the crank” and 
getting the final answer. 

This is exactly what we must do with a computer 
problem. The computer will “turn the crank” for us, 
but we must set up the solution procedure, for which 
we must first organize the problem into its logical 
components and procedures. 

We start with the initial problem statement, 
whatever it may be. It may be as simple as the state- 
ment we gave above, or it may be much more com- 
plex. No matter how complex it may be, however, it 
must be our starting point in program design. 


Documenting 


Program 
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Figure 1-1. The main steps of programming. 


For our example in this module, let us consider the 
problem of a checkbook maintenance program. 


Sector 2: Expanding the Problem Statement 


The statement that we want to keep our checkbook 
records on computer is the primary, simplified prob- 
lem statement. We will use this statement as our goal, 
or desired end result. However, before we can even 
begin the actual program design, we must expand 
this problem statement into a detailed statement of 
what the computer will have to accomplish. 

The first few requirements are easy enough. We 
want to include the number of each check, the date 
on which it was written, the dollar amount of the 
check, and the payee (the person to whom it was 
made out). We also want to keep a running balance 
for the account so that we will not spend more than 
we have in the account. 

The above items are what you would normally put 
on the check stub or recording booklet that comes 
with the checks. Therefore, we do not yet have any 


MODULE 2 


Defining and Attacking the Problem 


information that can’t be as easily maintained in the 
checkbook itself, without the need for a computer. 
However, some additional information which won’t 
fit in the checkbook is often desirable. Let’s consider 
the possibilities. 

Let’s include a flag, or marker, to indicate when 
the check has been canceled and returned to you. A 
second flag can indicate expenses that are tax deduc- 
tible. We can also include a description of the pur- 
pose of the check. We might also include the date of 
cancellation, and the month and year of the bank 
statement when the canceled check was returned. 
This last item will allow you to find the canceled check 
itself, if necessary, to prove that a payment was in fact 
made. 
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Figure 1-2. Defining the problem. 


Some banks include a check fee and/or a monthly 
service charge. These should be included in the 
program. Other banks pay interest on checking 
accounts, sometimes subject to conditions and 
restrictions. This should also be included. 

If your checking account includes a companion 
savings account, or if you have a separate savings 
account, it may be useful to maintain the savings 
records in the same program or file. If your checking 
account or savings account includes any other fea- 
tures, include them in the list. You may later decide 
to omit them from the program, but be sure to con- 
sider them before making your decision. Note any 
automatic deposits, withdrawals, and transfers so that 
you can include provision for them in the program. 
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Now we know basically what we want the com- 
puter to do for us. Let’s put the factors in an explicit 
list: 


e Record check number. 

e Record date check was written. 

e Record amount of check. 

e Record payee of check. 

e Maintain account balance. 

e Record date of cancellation. 

e Record date of statement when check was returned. 

e Mark tax deductible expenditures. 

e Record purpose of check. 

e Account for check fee. 

e Account for monthly service charge. 

e Account for interest earned. 

e Account for any penalty charges. 

e Record companion savings account activity. 

e Maintain savings account balance. 

e Record interest on savings account. 

e Account for automatic withdrawals. 

e Account for automatic deposits. 

e Account for transfers between savings and 
checking. 

e Record any bank card activities at automatic tellers. 


In looking over this list, note that we have included 
a few items that we didn’t mention originally. It will 
often be the case that, as you list items explicitly, ad- 
ditional items will come to mind. Be sure to list them 
along with the original ideas. Make your list as com- 
plete as you possibly can. Later you can drop an idea 
from the list if you have no need for it, but it is much 
easier to include an item from the beginning than it is 
to add an item to an existing program and then try to 
“catch up” all your past data. 
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LAYING OUT THE PROBLEM 


Now that we know what information we want the 
computer to keep track of, we must organize the 
individual requirements into logical groups. For 
example, individual check information must be 
entered at any time, as checks are written. This data 
may be updated daily or even more often, depending 
on how often you write checks. Any per-check 
charge should be automatically subtracted by the 
program as each check is entered. 

On the other hand, canceled checks, monthly ser- 
vice charges or interest payments, reconciliations, 
etc., must be updated monthly, according to when 
the bank statement arrives. Savings information must 
also be updated at different times, according to the 
specific activity. 

By organizing your operations in this way, you can 
simplify the logical requirements and structure of your 
program before you even start writing it. 


If your computer is available at this time, turn it on and 
insert your program disk into drive 8 if you have not 
already done so. Then, type in the commands: 
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LOAD “TRACK2’<return> 
RUN<return> 


Return to this point when your computer directs you to 
do so. 


Sector 1: Grouping Your Tasks 


We have broken down the basic Keep a Checking 
Account task into a number of individual tasks. 
However, different individual tasks must be per- 
formed at different times, and some must be per- 
formed more often than others for proper operation. 

The first step here is to determine the time frames 
that you will use in updating various aspects of the 
data. For example, some items must be updated 
daily, or as often as you write checks. These would 
be items relating to each check individually, such as 
check number, amount, payee, purpose, tax deduc- 
tible status, etc. Anything that relates to the individual 
payment or check should be entered as often as 
checks are written. 
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On the other hand, items dealing with the monthly 
statement should be entered or updated on a month- 
ly basis as the statements come in. Finally, an annual 
report may be required for business, inventory, or in- 
come tax purposes. Other time slots may be required 
according to your individual needs. All such time 
periods should be identified now to avoid possible 
problems later on. 

Figure 2-1 shows the breakdown we will use for 
our example problem. We have divided our list into 
three categories: those items which must be updated 
irregularly but often (usually every time you write one 
or more checks, or perform another transaction), 
monthly activities (performed when you receive your 
statement from the bank), and annual activities 
(normally related to income tax preparation). 

As before, we have added a few items in the pro- 
cess of grouping these tasks. Again, this is normal; as 
you list items and group them, you will often think of 
other items. Include these items as you expand your 
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lists. Keep in mind that the computer will make no 
assumptions about the completeness of your data. 
Rather, it will do exactly what you tell it to do, and 
nothing else. Thus, the more detail you include now, 
the better. 


VEC : HAV ELIGe LUE LENE LISpiay 


Once you have listed and organized all of the items 
you can think of to include as data in your program, it 
is time to sketch a diagram to define the organization 
of your data as you want it to be displayed on the 
screen or printed on the printer. Of course, it won't 
make much difference how the data appears as you 
enter it, but appearance can make a large difference 
when you display your data later on. 


NOTE: At this point, many computer users, es- 
pecially those who have used one or another of the 
many database management programs available on 
the market, may note that this type of operation is 
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exactly what a database system is designed to do. 
Therefore, there would seem to be no need to design 
a new program to do this job. 

This is true enough. However, the processes of 
defining the problem anzd its solution are still required. 
In this sense, you can consider a database manager to 
be simply another kind of language. In order to use it, 
you still must start by setting up the problem and your 
solution requirements on paper so that you can clearly 
define the solution procedure to the computer. 


Sketch the display as you will want it to appear on 
the screen. This will be the display used when you go 
back to your data to display it. It may also be (but 
need not be) the display used when you enter your 
data. Include the name of each field, and note the 
number of blank spaces required to contain the data 
for each field. Figure 2-2 shows the layout we will use 
in this example. The numbers in parentheses show 
the number of character positions allocated to each 
field. We will use these allocation numbers to help 
make sure that we don’t “run off’ the end of one 
display line and spill over onto the next line of the 
screen. 
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In this display, we have used a total of 38 character 
locations per line. This includes the number of spaces 
indicated for each entry plus a character space for each 
vertical line. The lines will be used as separators between 
fields. In addition, the header will require seven rows of 
the display, and the space for each check will occupy six 
more rows. 

Many computers have a 64 character per line display, 
while others have 80 characters per line. Such displays 
can show alllines of the required data in two rows of data 
rather than three. However, with the 40-character dis- 
play of the Commodore 64, we have less room per line, 
and we have 3 rows of data plus the lines in between. It is 
quite possible to use the high-resolution graphics display 
instead of the character generator, in which case you can 
have more characters per line and use fewer lines per 
check. For the present, however, our examples will be for 
the normal character display. 


In order to have room for all necessary information, we 


are using three lines of text for each checkbook entry. 


Otherwise the payee and purpose of the check, at 20 
characters each, would eat up an entire display line. Even 
ona wider display, we wouldn’t have room for much else. 


Figure 2-2. A sample layout for a check register display. 
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Using the display format shown in Figure 2-2, we still have 
room for more lines on the screen. This allows us to 
display three more entries on a 25 line display. The 
advantage of this is that it allows us to see as many as four 
checkbook entries at a time, just as we could with written 
check stubs. As we make new entries, we can still see the 
most recent entries. In addition, as we mark off cancelled 
checks, we can see both the preceding and the following 
checks. 

Of course, this layout is not final; it may be 
changed as necessary to meet your particular 
requirements. 


Sector 3: Automatic and Manual Entries 


Now let’s take a look at the checkbook task from 
another perspective: Which entries must be made by 
hand, and which can be handled automatically by the 
computer? 

For example, once we specify the individual check 
fee, the computer can automatically subtract it for 
each check written. In addition, the computer can 
automatically maintain the running balance and up- 
date this balance for each entry, whether it be a check 
or a deposit. The computer can also keep the se- 
quence of check numbers, although it will have to 
recognize deposits and automatic operations as not 
having check numbers. If the current date has been 
provided to the computer, it can also be entered 
automatically wherever it is required. 

On the other hand, the amount of each check, the 
payee, and the purpose must be entered manually, 
since no two will be alike during any one session. 
Also, 24-hour teller transactions will have to be 


entered by hand, as will the “tax deductible” flag and 
the monthly service fee. 

Automatic operations fall into two basic categories: 
items that will be the same for all entries in a given 
session, and items that will change progressively ac- 
cording to a predefined pattern. Thus, the date and 
check fee are constant values, and will not change 
from check to check. However, the check number 
must be incremented from entry to entry. This can 
easily be accomplished by automatically adding 1 to 
the present check number in order to get the next 
check number. 

Similarly, the running balance can be handled 
automatically by subtracting the check amount and 
the check fee from the old balance and by adding 
deposits as they are entered. 

At this point, we have defined the problem itself 
rather thoroughly. In fact, we have also come up with 
a few ideas for the solution procedure. Let’s go on 
now to define the procedures we will use to operate 
this checkbook. 
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DEFINING THE SOLUTION 


If your computer is available at this time, turn it on and Return to this point when your computer directs you to 
insert your program disk into drive #8 if you have not do so. 
already done so. Then, type in the commands: 
Now that we know what we want the computer to 
“LOAD “TRACK3”<return> do, we can begin to define the actual computer 
RUN<return> operations and put them in order. As shown in Figure 


Figure 3-1. Defining the solution. 
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3-1, we aren’t concerned with specific computer in- 
structions yet, but we are concerned with general 
procedures and sequences of operations. 


Sector 1: To Determine the Primary Computer 
Actions 


Earlier, we laid out our checkbook program re- 
quirements, and determined which actions could be 
performed by the computer and what would have to 
be supplied by the user. Now we will look at the 
specific actions to be performed by the computer and 
specify the required computer behavior. 

The first entry in the checkbook is the check 
number. This is a sequential type of number in that 
each check number is one greater than the previous 
check number. The computer can handle this easily 
enough simply by adding 1 to the last check number. 
Furthermore, the computer can automatically put the 
new check number on the display. 

Next, we have the date. Most computers with Disk 
Operating Systems request the current date as part of 
their initialization routines. Computers that start up in 
BASIC and have disk extensions to the main BASIC 
commands generally do not request the current date. 
In such a case, the BASIC program must request the 
current date as part of its initialization sequence. 

In either case, the computer program can be 
arranged to place the current date on the display 
automatically, either in the date of check or date of 
statement box, according to what you are doing at 
the time. 
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The check fee (if any) is a constant value and can 
be entered automatically. This value may change 
every few years as the bank adjusts its charge 
schedule. The remaining balance will be computed as 
soon as you enter the amount of the check. 


The other entries must be made manually for each 
check. The computer can position the cursor to each 
required box, in turn, to request that entry. It can also 
limit that entry to the desired number of characters 
and do whatever formatting is required. However, 
the actual data must be entered by the user. 


Sector 2: Checking for Exceptions 


We have already noted that the check number could 
be handled automatically by the computer. However, 
not every entry will be a numbered check. For 
example, deposits, automatic teller transactions, and 
monthly service charges do not have check numbers. 
Also, automatic deposits and withdrawals will have 
no check numbers. These entries must skip the check 
number and leave that box blank. 

Similarly, deposits and internal transfers are not 
subject to the individual check fee, but automatic 
authorized checks may be. Also, the monthly service 
charge does not show a check fee. 

These (and probably more) exceptions must be 
recognized somehow by the program, and appropri- 
ate boxes in the display cleared accordingly. That 
way, we will assign check numbers only to checks 
that we write, and check fees will only be charged 
where appropriate. As we come up with more excep- 
tions, we will add them to this list. 
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Sector 3: Defining the Sequence of Operations 


Earlier, we divided our checkbook task into three 
basic parts: entries to be made on a per-check basis 
whenever a check is written; entries to be made upon 
receipt of the monthly statement; and entries to be 
checked once a year for tax purposes. Each of these 
functions should be made separate from the other 
two, so that at any one session we will deal only with 
data for one kind of operation. In addition, we will 
want to include a “menu,” or selection guide, so that 
we can pick which operation we will perform in a 
single session. 

What we must do now is specify the sequence of 
operations to be performed for each individual part of 
the checkbook task. Since the menu will come first 
and is common to all parts, let’s start with it. 

Figure 3-2 shows the list of operations that will be 
performed when the program first starts up. The re- 
quest for the date may be part of the BASIC program 
or it may be requested by the Operating System 
when the computer is first turned on. In either case, 
for the purpose of this program, you should be sure 
to enter the correct date. 

Next, we want the computer to list the available ac- 
tions that might be taken. This is the “menu” itself, 
from which we can select the desired activity. Once 
the menu has been displayed, the program should 
wait for the user to input a selection. It should reject 
any invalid selections and wait for a valid input. Once 
it has received a valid input, the program should 
erase the menu and transfer control to the selected 
operating routine. Each of these routines should 
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return to the menu display when you have completed 
that particular activity. 

The most commonly used routine will be selection 
A from Figure 3-2. This is the selection that will 
enable you to enter new checks into your register. 


The program sequence for this routine is shown in 
Figure 3-3. 
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The first action listed is to retrieve the existing 
check register from disk. If no check register exists for 
the current year, the program must create an empty 
one, and then request the starting check number for 
that year. If a register already exists, the program 
must scan it for the last check number so that it will 
know where to start. 

Next we want to display the header, along with the 
empty check register entries. The last register entry 
will be placed in the top register space. This will usual- 
ly be the last check written, but it may also be a 
deposit or other transaction. The current account 
balance will also be displayed and will be read by the 
program. 

Once the display has been set up, the computer 
should display the next check number and the date in 
MM/DD format, and position the cursor to accept the 
payee of this check. Not all entries will be checks. 
Some will be deposits, service charges, 24-hour teller 
transactions, or automatic deposits, withdrawals, and 
transfers. In this phase of the operation, you may 
wish to record deposits, 24-hour teller transactions, 
and possibly any automatic operations. 

There are a number of ways to recognize these ac- 
tivities, but one easy method is to recognize special 
words as payee names. Thus, a payee name of 
“Automatic” or “Deposit” would immediately 
designate such an activity and would signal the pro- 
gram to erase the check number. Also, the word 
“Deposit” would signal the program to add the 
amount to the balance rather than subtracting it. The 
word “Quit” would end the session, while the word 
“Void” would indicate a destroyed check. 
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For any other payee, the computer would position 
the cursor to accept purpose of check, tax status, and 
amount of check. The computer should then fill in 
the fixed check fee (if any), and compute the new 
balance. 

Finally, the computer should save the completed 
entry, move it up one place on the display, and 
prepare for the next entry by blanking out the present 
data and inserting the next check number and the 
date on this blank space. 

The second menu selection is to reconcile the 
monthly bank statement with your checkbook 
register. We will use this selection to mark checks 
already written as having been received and canceled 
by the bank. The monthly statement fee and any 
automatic operations will also be confirmed at this 
time. 

To do this, the computer must search the register 
to find the selected check number (which we will 
enter for the computer to find). It will then fill in the 
Date of Statement box with a MM/YY format date. 
The date of cancellation is filled in at this time and the 
amount of the check is confirmed. 

Deposits, 24-hour teller activities, and automatic 
operations will be located according to the date of the 
transaction and the fact that they will have no 
assigned check number. The amount of the transac- 
tion is further confirmation that the correct transaction 
has been found. There is no cancellation date as such 
for these transactions, since they occur entirely on the 
transaction date. However, the statement date 
should still be filled in for future reference. 
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When you exit from this function, the program 
should add one more entry to the register: the 
monthly service charge. If this is a constant figure, it 
can be added entirely automatically. If there are other 
charges, they must be added manually before this 
routine returns to the main menu. 

The third menu selection simply scans the register 
for any entries marked as tax deductible. All such 
entries are listed to the screen. 

The final menu selection exits the entire program. 
When this option is selected, any changes that have 
been made to the register must be written back to the 
disk before the program terminates. 


Sector 4: Caveats (Things to Beware of) 


Of course, we know that our program will work cor- 
rectly, and that the data we enter will always be right, 
and that no corrections or adjustments will ever have 
to be made to our checkbook register. (If you believe 
that, I’ve got a bridge for sale in Brooklyn.) 

Seriously, it is very important that the program 
include the capability of correcting or modifying the 
data in our checkbook register. Errors may creep in at 
any time, and may not be noticed until later. Or you 
may find that you swapped check numbers for two 
payees when you wrote both checks before recording 
them on the computer. Or you might even have 
overlooked a check and not recorded it along with 
others. In that case, you will want to insert the missing 
check in its proper place. 

Corrections that affect the account balance must be 
carried through all succeeding entries so that the run- 
ning balance will always be correct. This may require 
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inserting a missing entry at any point, and then 
recalculating the balance for all following entries. 
Similarly, if the amount of a check must be corrected, 
that balance and all following balances must be 
corrected. 

This capacity — the ability to correct past and 
present entries — should be incorporated into every 
program you ever write, unless the concept does not 
apply to the program purpose. In general, the con- 
cept will apply to any program for which you must in- 
put data that will be saved by the computer for use in 
another operating session. Our LOAN program did 
not require this facility because it never had to save 
any of the data provided. Rather, it provided its 
display and then simply stopped. Another display 
would require additional inputs, and errors in input 
data are corrected by stopping the program and 
starting over again with the correct data. 


Another requirement that we overlooked before 
was the need to be able to scan through the existing 
checkbook register to see what checks have already 
been written. It would be nice to be able to search for 
a selected payee name or check number or to list all 
checks written on a selected date. We might also wish 
to search for a check written for a particular amount. 

A common requirement is to print out a list of all 
checks that match the desired criteria. This might be 
all checks for the month, all tax deductible checks for 
the year, all checks within a specified number range, 
or all checks written to a particular payee. 
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Fortunately, it is very easy to add plans for these extra 
items at this point in the programming process. The 
main question is whether to make these factors part 
of the existing menu, or to add new menu items to 
accomplish these tasks. 

If we catch an error while we are making an entry, 
we would like to be able to correct it at once. This 
allows us to correct the entry on the fly, as it were. 
However, there is no point in allowing us to correct 
previous entries while we are making a new entry. 
Therefore, we will make corrections a new menu 


item. 
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Similarly, we generally don’t want to scan entries 
or print them out while we are making other entries. 
Therefore, these functions will also be separate menu 
items. Figure 3-4 shows the resulting expanded 
menu. This is the new list of possible actions that will 
appear under item 2 in Figure 3-2. 

Our sequence of operations for entering new 
checks remains unchanged. The only change is that 
this routine must now recognize the cursor control 
keys (arrows) to move around and correct errors in 
existing fields in the current entry. 

Reconciling the monthly statement won’t change, 
except to allow the date of cancellation to be changed, 
if necessary. Also, of course, the “Exit” or “Quit” 
option will remain unchanged. 

We no longer show a separate option to retrieve 
tax deductible payments. Instead, we have two op- 
tions: to scan through existing entries or to print 
selected entries. These are similar to each other, ex- 
cept that the Scan option lists entries to the screen, 
while Print sends them to the printer. In addition, we 
have an entry correction option. We will need to 
define these three operations in more detail. 

Figure 3-5 shows the program sequence for the 


routine to scan existing register entries. We start by 
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displaying the end of the selected checkbook register 
so that the last check number is displayed. Also, the 
most recent entries are more likely to be wanted than 
are the earlier entries. 

The commands listed under Step 3 are only a few 
of the possible commands that could be included. We 
show the “S” key as a command to scan the register 
for a selected entry. The program would then request 
the field to be examined and the specific data to look 
for, and then scan through the register for the first 
matching entry. We might add the “N” key at this 
point to scan for the next matching entry. We might 
also add the “F” and “L” keys to go to the first and 
last entries, respectively. 

The “C” key command tells the program to shift 
into correction mode so that we can easily correct an 
error found while scanning, and the “Q” key tells the 
program to stop scanning the register and return to 
the main menu. 

In scan mode, the selected entry is placed in the 
middle of the screen, with an equal number of 
preceding and following entries, so that we can look 
over a group of entries at one time. However, no cor- 
rections are permitted in scan mode; we will have to 
shift to correction mode to accomplish this. 

The Print option is used to obtain a hard copy of 
part or all of the checkbook register. In this case, as 
shown in Figure 3-6, the routine will request the 
parameters to match, and will automatically scan 
through the entire register. For each entry, the 
routine will check to see if the selected field has the 
desired data for a match. If so, that entry will be 
printed out. If not, the routine will skip over to the 
next entry and check it. When the entire register has 
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been checked and all matching entries printed, this 
routine will return automatically to the menu. 

The correction option is outlined in Figure 3-7. 
This option can be entered directly from the menu or 
from the scan option. Similarly, we can go from the 
correction routine to the scan routine to find another 
entry to correct. 


Sector 6: Deleting Extraneous Factors 


Throughout this description, we have paid no atten- 
tion to maintaining savings records, even though we 
included a number of such entries in our listings in 
Track 2. The reason for this is that savings records are 
better kept separately, since the savings account is 
separate from the checking account and has its own 
independent balance. 

Of course, transfers to and from savings will affect 
the checking account balance and must be listed in 
the register. However, the changes to the savings ac- 
count balance should be kept in a different register, 
and will be handled by a different program. 

This sort of “pruning” of a program description is 
quite common. The idea of making both additions 
and deletions while the program is being defined is to 
make the program as complete as possible, without 
including extraneous factors that should really be 
handled separately. 


Sector 7: Adding Detail to the Outlines 


At this point, we have two choices of how to proceed 
with the generation of our program. We can go back 
to our outlines and increase the amount of detail 


specified in them, or we can go on to the next phase, 
which consists of mapping the solution using such 
procedures as flowcharting. Normally, the two are 
essentially combined into a single procedure in which 
the flowcharts are drawn with appropriate increased 
attention to detail. As this is done, additional re- 
quirements come to light which probably would not 
appear in just the outlines. 

We will cover flowcharting and the expansion of 
the program outline in a later module. In the mean- 
time, the outlines that we have developed are suffi- 
cient for this stage of programming. 

For the present, let’s skip past the mapping pro- 
cedures and take a look at a practical program that 
will create and maintain checkbook registers on a 
year by year basis, as we have already defined it. 
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The preliminary checkbook register program is on the 
disk that accompanied this module, with a program name 
of “CHECKBOOK’” in the disk directory. As with most of 
the programs in the Series, it is written in BASIC. If your 
computer is available at this time, turn it on, insert your 
program disk into drive 8, and type in the command: 


LOAD “CHECKBOOk”,8<return> 


Do not attempt to RUN the program yet, as it is 
incomplete. We will look over the program and work 
with it before we attempt to RUN it. 

With the program loaded, you can LIST the pro- 
gram lines as they are described in the text. For 
example, to examine lines 10 through 90, type in the 
command: 


LIST 10-90 <return> 


and the computer will display those program lines for 
you. Do this now. Then as we proceed with the 
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discussion, LIST the corresponding lines on your 
display. 

The figures in this Learning Guide show the program 
listings for the Commodore 64 computer, and the C128 in 
C64 mode. Other computers may use slightly different 
command sequences to perform the same tasks, but the 
basic operation will be the same. 


If your computer is not available at this time, the 
figures will still help you to understand what the com- 
puter is doing. However, we suggest that you repeat 
this track later when you have a computer available. 


Sector 1: To Explore the Program Organization 


In order to maintain a reasonable program structure, 
we have allocated line numbers 1 through 999 to 
initialization and program setup. This is where the 
initial data will be entered, and where the main menu 
will appear. 
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10 rem contemporary software design 
15 rem module 2, checkbook program 


20 rem preliminary version for 
25 rem demonstration & practice 


40 rem megraw-hill 


45 rem continuing education center 


sO ram S9S9 wisconsin avenue, mw 


SS rem washington, dc 20014 
60 rem 
7O rem 
80 rem 
oO rem 
ready. 


Figure 4-1. The comments at the beginning of the checkbook program. 


Line numbers 1000 and above will be used for the 
different menu options, with each option being 
allocated its own group of 1000 lines. Thus, menu 
option 1 will have line numbers 1000 through 1999, 
option 2 will have 2000 through 2999, and so on. 


We begin the program with the usual comments sec- 
tion (lines 10 through 90), as shown in Figure 4-1. These 
comments identify the program and indicate that it is a 
preliminary version that will be modified and extended to 
make it complete. 


Sector 2: The Initialization Section and Main Menu 


Program lines 100 through 170, shown in Figure 4-2, 
begin the initialization. We start with a clear screen of the 
selected colors, switch to lower-case letters, and then 
center the program title on the top line of the screen. 


Some computers request the current date and time 
when they are first turned on. They maintain an internal 
system clock and calendar. Since the Commodore 64 
does not maintain the current date, the program will 
request this information and keep it in the variable da$. 

When you type in the date for line 130, be sure to use 
the exact format shown (MM/DD/YY), with two digits 
for each number and slashes between them as separa- 
tors. BASIC will be using different parts of this string in 
the display. If you wish, you can replace the slashes with 
hyphens (-). In that case, your display will show hyphens 
rather than slashes for all dates as the program runs. 

Lines 140 through 170 determine whether or not you 
want to use the checkbook register for the same date that 
you typed. This allows the program to maintain different 
registers for different years, and still update them or 
examine them at any time. 
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100 rem initialization phase 
195 rem 
119 poke S3280,14:poke S5S3281,14 
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120 printchr$(14);"CBLUICCS] CHECK ROOK REGISTER MAINTENANCE FROGRAM" 


120 printrinput"What is the date 


(MM/DD/YY) “sdat 
140 input"Are you using this year’s checkbook 


(y/n) "sat 


150 if af="y" or at="Y¥" then yr#=right$(da$,2):goto 200 
160 input"What year*s checkbook doa you want":yr% 


170 yrS$=right#("OO"+yrs, 2) 
ready. 


Figure 4-2. Getting the initial information. 


Sector 3: Reading or Creating the Data File 


Lines 200 through 290, shown in Figure 4-3, introduce 
some new instructions and a new concept in program- 
ming. Here, we begin to deal with the data file. 

Over the course of a year, our checkbook register 
will acquire hundreds, perhaps thousands, of new 
entries. We could keep rewriting the BASIC program 
and incorporate each new check and deposit as data 
within the program itself. However, this is clumsy and 
error-prone, and makes updates difficult. What we 
want is a means of maintaining our checkbook in a 
way that is separate from the program itself, and yet 
can be used by the program. In addition, this will 
allow the same program to handle separate check- 
book registers for different years, and still access any 
desired register. To accomplish this, we must main- 
tain each checkbook register as a separate data file 
on disk. 

A file is any single block of data on a disk. Each file 
will have one directory entry to identify that file and 
its location on the disk. A file may be a BASIC pro- 
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gram, a machine-language program, or a block of 
data. Each program on the enclosed disk is a single 
file and has its own directory entry. 


The CHECKBOOK program will create, modify, and 
extend a new kind of file on your disk: the data file. This 
kind of file is not a program in any sense. It contains only 
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BOO rem open or create data file 


4o0 


250 printrprint"This is a new checkbook register. Is 


tH eSOo:am=61 2 ¢ 26a 


t =OHSs bas? 
, ‘register "+y#+",1, "tchr$(82):gosutb 900 


260 input"this what you want (y/n) "sags 


270 if at="y" of at="¥" then 200 


Ciera 2 


280 closel:closef:open 1,8,15, "srregister"+y$iprint#i, "i":closel 


290 -gote-—rou 
ready. 


Figure 4-3. Setting up the data file and buffer. 


data which can be read or written by the CHECKBOOK 
program. It is this data file which will contain the actual 
data for your checkbook register. The CHECKBOOK 
program will use a different data file for each calendar 
year so that you will be able to more easily locate specific 
entries. 

Line 210 is used to define a number of pointers into our 
data file. We will use these variables to determine where 
within any given record we will look for a specific data 
item. For example, the check number, cn, will start at 
location 1. The check date, cd, will start at location 5 
within the record. This means that location 4 will be the 
last character used for the check number. The remaining 
variables define the starting points of the remaining items 
within each record. 

Line 220 is the actual OPEN statement. This command 
tells BASIC to look for a data file on the disk, or to create 
one if it does not already exist. In this case, we must 
actually open two files to the disk drive. We'll see why as 
we look at the parameters that must be included in the 
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OPEN command. These parameters are: 


1. The buffer number for this file. This number refers 
to an area of memory that will be used by BASIC to 
handle data for the file. Each number can only refer toa 
single file at any one time. Later references to the file will 
be made by using this number only. The buffer number 
must be between 1 and 15. 

2. The device number on which the file resides. For 
the primary disk drive, this will be 8. Additional disk 
drives can be 9, 10, and 11. The printer is normally device 
#4. We will be using device #8, since this is the default disk 
drive for all of our operations. 

3. The channel number or secondary address, depend- 
ing on the specific device being accessed. This number 
can be used to set a device (suchas a printer) to a specific 
mode, or to define the purpose of the file. For disk files, 
channels 0 and 1 are used internally, only for SAVE and 
LOAD commands. Channels 2 through 14 are available 
for general use. Channel 15 is the command/status 
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channel. This channel is used to send commands to the 
drive itself, or to check for errors reported by the disk 
drive. You must open this channel to control access to 
random-access disk files. For some devices, such as 
printers, this and further parameters are optional. 

4. The file name or command string. This is a charac- 
ter string that will be sent over the specified channel to 
the device being opened. If it is the disk drive command 
channel (15), this could be a command to either format 
the disk, initialize the drive, or to perform any other 
command operation. If it isa data channel (2 through 14), 
it is the file name and any data concerning the file. In line 
220, it is the file name REGISTERyy, where yy is the 
specified year, the letter L, and a binary number specify- 
ing the size of a single record in this file. 

The subroutines at lines 800 through 940, as shown in 
Figure 4-4, serve to work with the disk files. The subrou- 
tine converts a record number into two individual bytes, 
and then instructs the disk drive to point to the desired 
position of the specified record within the file opened on 
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channel 8. Then, the subroutine at 900 reads the error 
channel to determine whether or not the operation was 
successful. The subroutine carefully ignores error 
number 50, which indicates that the specified record 
does not exist. This allows you to still write to that record, 
thus creating it and any previous records that did not 
already exist. 

Back in line 230, we use these routines to position the 
disk drive to the start of record 1 in our file. If there is no 
error, the file already exists and we can skip the initializa- 
tion. If there is an error, line 240 will detect it and will pass 
control on to line 250. 

The remaining lines in Figure 4-3 advise the user that 
this is a new file, and request confirmaion that this is what 
is wanted. This allows the user to recover easily in case of 
a mistyped year or other typographical error. If there was 
an error, line 280 closes all files, scratches (erases) the 
wrong file just created on disk, and re-initializes the disk 
drive. Then, line 290 returns control to the start of the 
program to let you start over. 


Sector 4: Placing the Initial Data in the File 


If this is a new file, the program needs some initial data 
to get started. It requests this data and initializes the data 
file in lines 300 through 390. 

The three basic items required are the first check 
number, the per-check fee (if any), and the starting bal- 
ance. As shown in Figure 4-5, the program requests these 
three items and writes them to the first record in the file. 
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800 rem convert rec# to two bytes 
BOS rem 
B10 ch = aa 7255) 


820 rl fe ACen ed 
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830 print#i, "p"schr$ (104) gchr(rl) gchrs(rh) ychrs (po) 


8935 rem 

900 rem check for disk error 
SOS rem 

910 input#i,e,m$,c,d 


920 if e=50 or ef20 then return 
920 print"Disk error: "serm$ici3d 
940 end 

ready. 


Figure 4-4. Handling the disk drive command/error channel. 


Data placed into random file records can have any 
meaning, but must be transmitted in string form. There- 
fore, each item of information is converted to a character 
string of the required length. If the string does not occupy 
the entire allocated space, it is padded with leading 
blanks or spaces so that numeric values will always be 
justified right in their specified fields. We have allowed 
four characters each for check number and per-check 
fee, and 8 characters for the account balance. This allows 
check numbers as high as 9999, a per-check fee up to 
$9.99, and account balances to $99999.99. This will nor- 
mally be adequate for a personal checking account. 


Es 
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We use record #1 to store these values for use any time 
the file is updated. That way, we can always find this data 
without having to hunt for it. We will update this record at 
the end of each session with the program, so this data will 
always be ready for us at the start of each new session. 

Finally, we create a string (BL$) of 82 spaces, and use it 
to create a blank record #2 in this file. 


Sector 5: Getting the Initial Data from the Disk 


If the file already exists on the disk, we don’t want to 
initialize the file. Instead, we simply want to read the 
current status directly from the file. This is the job of 
the lines in the 400s, shown in Figure 4-5. 

In these lines we recover the initial data from record #1 
in the file. This is necessary, because after the first time 
we create and use this file, we will not be manually stating 
these values for the program. 

In lines 420, 440, and 460 the GET statement tells 
BASIC to recover one character from the file, at the 
current pointer location. So, in line 420 we GET all four 
characters of the next check number to be used. Also, in 
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rem get initial data for file 
rem 


engs=rights¢" "teste $ (mm) .4) 
r=Lliporecnigosub B00:rprint#e, cn€; 


"+h (rn) 4) 


r=lrpo=cfigosub 800rprint#e, cf %; 


bat=rightst" Hate ee: gc 
r=lipo=basgosub 800:print#2l, bass 
r=Eeporl:gosub B00 

ble." 

print#2,blts 


ready. 


Figure 4-5. Inserting the initial data. 


input"CCDIWnat is the first check number for this register”’yn 


input"CCDIWhiat is the per-check charge” sn 


input"CCDIWhat is your starting balance’in 


SSR ROLE SS NS Se RS ET EE TS EE SE NEE RR EE STE SEE TES IS SITS EE SR TR 


4 


400 rem read initial data from record ft 


4on rem 

410 r=lipo=cnigosub 800:cns="" 

420 for i=l to 4:qget#2 n&icns=cnst+nis: 
420 r=lipo=cefigosub BO00:cF#s="" 

440 for i=l ta S:qet#S néscf s=cfSt+ns: 
‘SO m=elspo=bargosub BOG: bags="" 

460 for i=i to S:get#s ntibas=batt+ns: 


ready. 


Figure 4-6. Getting the initial status from the file. 


mext izck=val tens) 


next isch=val tcf) 


next i:nb=val (ba) 


line 440 we GET all four characters of the per-check bank 
charge. WAIT AMOMENT! The FOR-NEXT loop in line 
440 calls for 8 characters rather than 4. This is an error 
and should be corrected as soon as you start working 
with the program. However, line 460 correctly GETs all8 
characters of the present account balance. 

This type of error is easy to make. Be sure to take note 
of such an error as soon as you catch it, so that you can 
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correct it as soon as possible. You will be working with 
this program a little later on; you can make this correc- 
tion at that time. 


Sector 6: The Main Menu 


The lines in the 500s, shown in Figure 4-7, display the 
main menu for this program. This group of program lines 
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BOO ream display the main menu 


SS oy ts noes 
wot em 


pag 2 Dead feaet eee 2 Ss el Se | as |B REGISTER MATNTENGANCE FROGRAM” 


Bao print LebIteoA 


Dok prises cos 1. Enter new checks, transactions 
Reconcile monthi y 
Scan checkbook regi 
Frint selected entries” 
Correct an entry’ 


3 


S40 prick : 
pal pe) Gr or get 1S 3 
Soe Pew 
we pe ee 


pa ee oy ae ree 


rol tb 


End program" 


f 
i 
e 


ready. 


Figure 4-7. The main menu. 


at 
we hn 


MENU" 


Pal 


atement" 


ter” 


| RS SS SS SS SS SM RR SS SSSR SS EE 


consist of nothing more than a series of PRINT state- 
ments, using the cursor motion keys to produce a neat, 
easy-to-read display. 

Next, the lines in the 600s, shown in Figure 4-8, 
request the user’s input, make sure it is valid, and 
then execute the appropriate routine according to the 
selected menu option. Here, line 620 checks the 
selected input and makes sure that it is a legitimate 
number between 1 and 6, to correspond to the listed 
menu options. If the input does not fall within this 
range, the IF statement tells BASIC to go back to line 
610 and request the input again. 

Once a valid input has been obtained, line 630 
picks the line number at which the selected routine 
will start. It does this by means of the ON ... GOTO 
statement. This arrangement is used to select one of a 
list of line numbers and continue program execution 
there. The ON keyword tells BASIC that this kind of 
structure is being defined. This command is followed 
by any numerical expression (We used the simple 
variable S) that will be evaluated to a positive integer. 
The GOTO command is followed by a list of program 
line numbers. BASIC will pick a line number from the 
list according to the integer value of the expression 
that followed ON. That is, if S = 1 in line 630, 
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BASIC will pick the first line number and go to line 
1000. If S = 2, BASIC will pick the second line 
number in the list. (Line 2000 in this case.) 

Use care with this type of expression. If the expres- 
sion is negative, BASIC will stop and issue an error 
message. If it is zero or if there aren’t enough line 
numbers in the list, some versions of BASIC will fall 
through to the next line, while others will issue an 
error message. In line 630 of Figure 4-8, we already 
know that the number must be between 1 and 6, and 
we have provided six line numbers, so there will be 
no problem. 


Sector 7: Ending the Session 


At any one session with the computer, you may add 
many checks, a few checks, or none. You may do 
any of a number of things. However, regardless of 
what you do, you will want to be sure that all of your 
updated records are written to your disk file, and 
that your latest check number and final balance are 
correctly saved in record #1. 


To ensure that everything is correctly saved and 
that your checkbook register file is properly closed, 
always end your session with this program by select- 
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RS SS SCS 


600 rem select and @xecute menu option 

oom rem 

So Ppt CHE TERI Pep ECD IEC DA LER IEC pS LEDC ep eCe EEO Eee A ECR abe ba 
[CDIFlease enter your selectian Paps Fees 9 ei Ha) 1? 2 De Pf Pt ee UP 6 re 

620 af s<1 or s*6 Then 610 


620 on Ss goto 1000, 2000, 2000, 4000, S000, 700 


reacy. 


Figure 4-8. Selecting the menu option. 


ing menu option 6. This will cause BASIC to select 
the sixth line number in the list in line 630, which in 
this program is line 700. Figure 4-9 shows this set of 
line numbers. 

This part of the program starts by clearing the screen 
and placing an appropriate message on the screen. Then, 
starting in line 720, write the latest values for check 
number, per-check charge, and account balance back to 
record #1 in the file. 

Line 780 uses the CLOSE command to reverse the 
action of the OPEN commands back in the 200s. The 
CLOSE command is always followed by the buffer 
number associated with the file to be closed. This is the 
first number that followed the original OPEN command, 
and each buffer must be CLOSEd separately. The 
CLOSE command tells BASIC to make sure that all data 
left in the buffer is actually written to the disk drive, and 
that the drive is told to record everything onto the actual 
disk. The drive then updates the disk directory to reflect 
any change in the size of the file and marks the file as 
being no longer in use. 
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Finally, we move the cursor several lines down the 
screen, after which line 790 tells BASIC that this is the 
‘END of the program. BASIC therefore terminates pro- 
gram execution and returns to command mode. 
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70QO rem orderly exit from program 
70S rem 


710 print "CCSICCDICCDICCDICCDICCDI x x x 


720 r=lipo=cnigosub 800 
730 cns=rights¢" 
740 r=Llipo=cfirgosub 800 
750 cf$=rights(" 
760 r=lipo=basgosub 800 
770 bat=right#(" 


ENDINGCISOIJPROGRAMEC160]x xk *" 


"+tstr$(ck),4) :print#2,cnss 
"+str$(ch),4)sprint#2,cf$: 


"+str$(nb),8) sprint#2,bagss: 


780 close i:close 2:print"CCDICCDICCDICCDICCDILCCDICCDICCDICCDICCDI" 


790 end 


Figure 4-9. Ending the program sesion. 


1000 rem enter new checks 


2000 rem reconcile monthly statement 


S000 rem scan current register 
4000 rem select and print entries 
S000 rem enter corrections 


6000 goto So0:rem return to main menu 


ready. 


Figure 4-10. Identifying the active program routine-entry points. 


Sector 8: Setting up the Menu Option Routines 


We can't just punch in the routines for the main menu 
options all at once. These will take some additional 
planning. However, we can at least place a comment 
line at each of the line numbers listed in the ON ... 
GOTO statement of line 630. We can also add a final 
line to send BASIC back to the menu if, in testing the 
program, we select a menu option that has not yet 
been implemented. Figure 4-10 shows these program 
lines. 

By placing these lines in the program, we can test 
the operation of the initialization and menu routines 
before we install the actual option-handling routines. 
Then we can make sure that the file-handling instruc- 
tions will work correctly, and that the part of the pro- 
gram we already have will not be likely to cause more 
problems in the routines that we will add later. You 


will perform such testing on this program later in this 
module. 

In the meantime, let’s take a look at another exam- 
ple of problem definition and solution outlining with a 
phone book/mailing list program. 
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DEVELOPING A PHONE BOOK/MAILING LIST 


PROGRAM 


Almost everybody keeps a personal “phone book” 
that lists names, addresses, and phone numbers for 
friends -and relatives, doctors’ offices, schools, 
businesses, etc. The book is set up for maintaining the 
list in alphabetical order, and individual entries may 
be inserted or deleted at any place and at any time. 
If the list is small, it is probably best kept on paper 
where there is no overhead in loading a program and 
its data into the computer. However, if it begins to ex- 
ceed about 100 entries, the time required to search 
the book begins to be as much as the time required 
for the computer to load its program and data and to 
search through the data for the desired entry. In addi- 
tion, the computer can add or delete entries and 
alphabetize them correctly without using paper. 
Many people use these address books to keep 
records of Christmas card activities, birthdays, and 
similar information, as well as the basic name, ad- 
dress, and phone number. With these possibilities in 
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mind, let’s define the problem and the computer 
solution for such a mailing list. 


If your computer is available, turn it on and insert your 
program disk into drive 8. Then type in the commands: 


LOAD “TRACK5”<return> 
RUN<return> 
Return to this point when the program directs you to do 
so. 


Sector 1: Defining the Problem 


As we stated earlier, the very first step in designing a 
program is to clearly define just what we want the 
computer to do. Figure 5-1 shows the basic list of 
tasks to be performed by our phone book/maailing list 
program. The tasks are listed in three groups: visual 
display, printer output, and list modification. As 
usual, we may think of additional items as we go 
along, but this will serve as our initial task list. 
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SE Figure 5-1. The preliminary list of tasks for the telephone mailing list program. 


The first group is concerned with displaying infor- 
mation currently in the list. The information will ap- 
pear on the video screen, and will not be directed to 
the printer. All of the information specified in this 
group will be displayed at once, provided it has been 
entered into the list previously. Of course, you would 
not normally include Christmas cards or birthdays for 
a business acquaintance, nor would you generally in- 
clude a business name for a friend. However, you 
might want the business phone number of your friend 
as well as the home number, since it might be 
necessary to get in touch during working hours. 

The second group deals with the printer. General- 
ly, a printout of name and address is entirely satisfac- 
tory for mailing labels. However, you might wish 
other printed outputs for your own specific purposes. 

The third group comes under the heading of 
“editing” the list. This concerns any change to the list, 
whatever its nature. Normally, this will consist of 


Figure 5-2. The format of the printed mailing label. 


either adding a new entry, deleting an old entry that 
no longer belongs in the list, or correcting or updating 
an existing entry. You might want to do this when 
somebody moves or changes their phone number so 
that your list will remain up-to-date. 


Sector 2: Laying Out the Display 


The next step is to specify the layout of the video and 
printed displays as they will be generated by this pro- 
gram. The mailing label format is easy enough, since 
this is basically a standard format already. Figure 5-2 
shows this format. A foreign country would require 
appropriate variations in this format as well as a coun- 
try name. The necessary variations are small and 
consist mainly of adding a fourth line for the name of 
the country. The third line could be altered in the list 
to handle any other variations. 
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_ Figure 5-3. The video display format for the phone book/mailing list program. 


The video display will contain all of the informa- 
tion, so it will be more complicated. However, we only 
need to see one entry at a time, so we can devote the 
entire screen to the purpose. 

Since we will normally look up somebody by their 
last name, we will put the last name first on the 
display. Then we will have the first name and (if 
desired) the middle initial. The address will follow, on 
two lines, in standard address format. We will include 
a line for country, since this may well be required, 
especially when printing out labels. Then we will 
place the home phone number and the business 
phone number under the address. 

At this point, we could assign separate spaces for 
Christmas card flags, childrens’ names, birthdays, 
and other information. However, much of this infor- 
mation is mutually exclusive. That is, if you have a 
business name and address, you may not be in- 
terested in personal information or in sending 
Christmas cards. On the other hand, personal listings 
such as friends and relatives may not need business 
information. Therefore, let’s just leave the rest of the 
record available for general notes, which may contain 
any desired data. Figure 5-3 shows the resulting 
layout. 
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Sector 3: Outlining the Solution 


As with the checkbook program, we will start with a 
menu that will let us decide whether to add an entry, 
delete an entry, modify an entry, display an entry, or 
to print mailing labels. Figure 5-4 shows the basic 
sequence of operations for the menu. 
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The first menu selection is to add an entry. The 
sequence for this option is shown in For 
this option, we will want the computer to first input all 
of the appropriate data. Then it will scan through the 
present list to locate the correct place for the entry. 
However, before it actually inserts the new name, it 
should check to see if that name is already present in 
the list. This will help to prevent duplicate entries. 
Nevertheless, the option to keep both entries should 
be included because it is possible for two people with 
different addresses to have the same name. We don’t 
want the program to automatically consider them to 
be different because we may be dealing with a single 
person who has just moved rather than with two dif- 
ferent people. The program can’t tell, so it must ask 
the operator to make the decision as to what to keep 
and what to drop. 

Figure 5-6 shows the sequence of operations 
required to locate and delete an entry from the list. 
Here the most common choice will be to delete a 
name from the list. However, we may prefer to delete 
one or more entries according to some other 
criterion. Therefore, the program should request the 
field, as well as the data, to compare that field with. 

Once a match has been found, the matching entry 
should be displayed and confirmation requested 
before the entry is actually deleted. This way, we 
won't find that we have deleted more entries than we 
meant to eliminate. If we confirm that we want to 
delete the entry, the program should blank that entry 
and close up the list. 

Whether the selected entry is deleted or not, the 
program should then continue its scan through the 
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list, searching for another possible match. This 
process should continue through the entire list. 

The routines to modify or display an entry will be 
very similar. Figure 5-7 shows these two routines. As 
shown in the figure, the only difference between the 
two routines is that the display routine does not 
include modification capability. For this reason, we 
might just as well combine these two options into a 
single routine and permit modifications to be made 
from the display routine. This will eliminate menu 
option C in Figure 5-4, and simplify our final pro- 
gram. 

The final option is to print mailing labels. For this 
option, we will want to print name and address, and 
possibly country as well. However, we may want to 
select the entries to be printed according to some 
other field. To do this, we want to be able to specify a 
field to scan, just as we did for the delete, display, 
and modify options. Figure 5-8 shows the steps we 
will need to accomplish this. 
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Sector 4: The Resulting Phone Book/ Mailing List 
Program 


The preliminary phone book/mailing list program is 
on the disk that accompanies this module, with a file 
name of PHONBOOK. It is written in BASIC, as are 
all of the programs on this disk. 


If you have your compter available, turn it on, insert 
your program disk into drive 8, and type in the 
command: 
LOAD “PHONEBOOK”<return> 
Then as we discuss each group of program lines, you can 
LIST them on your computer. 
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10 rem contemporary programming and 


15 rem software design: module 2 


2o rem phone book/mailing list program 


20 rem preliminary and incomplete; 
25 rem to be expanded 


45 rem copyright (c) 1984 by 
30 rem mcgraw-hill, inc. 


60 rem megraw-hill 

65 rem continuing education center 
70 rem 39239 wisconsin avenue, nw 
75 rem washington, dec 29016 


Figure 5-9. Initial comments for the phone book/mailing list program. 


100 rem startup & open disk file 
105 rem 

119 poke S3280,14:poke 33281,14 
120 peintches Ges FBEYIceSs 


PHONE BOOK and MAILING LIST HANDLER"; 


130 input"CCDICCDICCDIWhat is the name of your data file on disk":f1¢ 
140 open 1,8,15:o0pen 2,8,.8,f1%+",1,"+chr$(254) :gosub 900 
150 r=lspo=ligosub 800:if e=O then 200 


L60-prant"LeDA ys Fiss" isla new file." 


170 input"Is this what you want"sas:if a$="y" or af="Y" then 200 
180 close 2:iprint#1, "si"+flS$iprint#i, "i":sclose 1 


190 goto 100 


ready. 
Figure 5-10. Starting the phone list program. 


The figures in this Learning Guide show the program 
lines for the Commodore 64 computer. If you are using a 
different computer, your listing will be slightly different, 
but the program lines will accomplish the same purpose. 


If you type in the command: 


LIST -90 < enter > 


the program lines shown in Figure 5-9 will be 
displayed on the screen. As before, these are the 
comment lines at the front of this program. 

Lines 100 through 190, shown in Figure 5-10, 
start up the program, produce the initial display, and 
open the selected file. If the file is a new one, it asks if 


£ 


you intended to start a new file. If so, the program 
continues normally. If not, it kills the file from the disk 
and then starts over. 

Note that we are not concerned with the date in this 
program. We don’t really care when an entry is inserted 
or deleted from the file, or how longit has been there. It is 
the content of the entry, not its date, that is important. In 
addition, we have made no effort to name the data file 
automatically. Unlike the checkbook register, there is no 
single logical name for the data file, and you may wish to 
maintain several of them. Therefore, you can pick any 
name you like for each file. 
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2OO rem define file fields 
rem 
ln=lLina=21imi=26é:ad=27:ct=71sst=96 
ns=LeSsmn4=222 

ready. 

Figure 5-11. Fielding the file. 
rem display the main menu 


rem 


print LeSt (PHONE BOOK 


Ss wah rp ke 6. End this session. 


ready. 


Figure 5-12. The main menu. 


and MATLING LIST HANDLER": 


print "fCpIlep 1. Add an entry to the file." 
reps AL 2. Delete an entry from the file." 
Brite 3. Edit an entry in the file." 

Br tates 4. Display an entry in the file." 
prime” o. Print marlong Labels, © 


LS 


In line 140 when we open the control channel and data 
file, we specify a file length of 254 characters. This is the 
maximum record length permitted in Commodore 
BASIC, and each record will occupy exactly one sector 
on the disk. (Each sector is actually 256 characters long, 
but two of these are used by the drive to point to the next 
sector in the file.) 

Figure 5-11 shows how we have fielded the file. We 
have allocated space for Last Name, first NAme (we 
couldn’t use FN because that is a reserved keyword), 
Middle Initial, ADdress, CiTy, STate, ZiP code, Home 
Phone, and Work Phone. This leaves us 132 characters 
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for notes, etc. Rather than make any more specific 
entries, we allocated 33 characters for each of four lines 
of notes. A country or other mailing information can be 
placed on one or more of these, to be optionally printed 
out later, if necessary. 

The lines in the 300s, shown in Figure 5-12, 
display the main menu on the screen. This is very 
similar to the menu we examined for the CHECK- 
BOOK program. It appears at a lower set of program line 
numbers simply because fewer preliminary operations 
were required. 
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400 ream select and Grecute menu option 


4O5 ream 


4190 input"CHCILCDICCDICCDICCDICCDICCBDICCDICCDICCDICCDIFPlease enter your 


selection 


$20 LF se or e24 then 410 


BCL CLT Eel aECEA EEL AECL Iss 


1 
420 on s goto 1000, 2000, 2000, 4000, 5000, 500 


ready. 


Figure 5-13. Selecting and executing a menu option. 


a 


SOO ream orderly @xit from program 
205 rem 


SOS print slo oStel ha LCP I Le ps rep Diek ss 


S20 close isclose 2 


ENDINGCI6CIFROGRAMLCI607% * x" 


S20 jpPane be pT ECD EEDILED TEED ILEDITCRILEDILEDILERA 


S40 end 


reacly. 
Figure 5-14. Ending the program. 


1000 rem add an entry to the file 


SOOO ream delete an entry from the file 


SOOO ram edit an emtry in the file 
4000 rem display an entry in the file 


2000 rem print mailing labels 


6000 rem gota 2O0:rrem return ta menu 


ready. 


Figure 5-15. Preparing for the option-handling routines. 


Then, as with the CHECKBOOK program, we request 
the desired menu option and execute it. This occurs in 
the 400s, as shown in Figure 5-13. 

Also, as with the CHECKBOOK program, the final 
menu option here is to end the program. This option 
continues program execution at line 500, shown in Figure 
5-14. In this case, we do not want to keep any special 
information in record #1, so we need not update this 
record as we did in CHECKBOOK. For PHONEBOOK, 
the CLOSE statements are sufficient. These commands 
will make sure that all records that have been written to 
the file buffer are actually written to the disk, and that the 
disk directory entry is updated if necessary. 


Finally, as with the CHECKBOOK program, we have 
installed comment lines at the start of each set of pro- 
gram lines allocated for the menu selection options. Fig- 
ure 5-15 shows the last lines presently included in this 
program. Line 6000 is present to permit testing of various 
program operations without having to type in RUN for 
every test. 

Of course, neither of these programs will do any- 
thing yet, except create initial data files on your pro- 
gram disk. We will add the individual working 
routines and test them one at a time in succeeding 
modules. 
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PRACTICE PROBLEMS 


i 


p— 


a 


One of the most important requirements for learning 
any new skill is practice. Whenever you do 
something for the first time, you don’t expect to do it 
perfectly. However, it is still a valuable learning 
experience, and you know you will do better the 
next time. As you continue to practice, you become 
better and better at it. 

This same pattern holds true for programming. 
Nobody expects you to sit down and write a major 
program from scratch. Even a highly experienced 
programmer would not work that way. However, as 
you become more familiar with the overall program- 
ming process, you will find that some phases of pro- 
gramming become more and more familiar, and you 
will be able to handle them more easily as time 
goes on. 

At the same time, we will introduce new phases of 
the programming process which will build on knowl- 
edge you already have. And in each module we will 
include programs on which to work and practice. 
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Now it is time to get in some practice with real 
programs on your computer. Let’s begin with the 
LOAN program you worked with in your previous 
module. 


Sector 1: The Expanded LOAN Program 


One of the programs on the enclosed program disk is 
named FINAL LOAN. This is the expanded LOAN pro- 
gram containing all of the extensions and features we 
suggested you try to add at the end of Module 1. 

To compare this program with your own version, 
LOAD your program. Then, with your printer connected 
and turned on, type in the following command sequence: 


OPEN 4,4<return> 
CMD 4:LIST<return> 
PRINT#4<return> 
CLOSE 4<return> 


This series of instructions will cause your computer to 
LIST your program to the printer (device #4) instead of to 
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the screen. The PRINT#4 command restores output to 
the screen. 


Next, LOAD the FINAL LOAN program and then use 
the same command sequence to list it to your printer. 
Now you can compare the two printed listings. 

If you don’t have a printer for your computer, you can 
alternately LOAD the two programs and either compare 
segments of listings on the screen, or manually copy key 
program lines from the screen for one program, and then 
compare them with the screen listing of the other one. 


Even if your listing is somewhat different from 
ours, that doesn’t mean it is wrong. On the contrary, 
if it works correctly, it is a satisfactory program. The 
proof of this is to RUN both programs with several 
different sets of test data. If they produce the same 
results, they both work. 

When you run FINAL LOAN, check the spelling of the 
word PRINCIPAL on the display. The original spelling on 
your first disk was PRINCIPLE. Did you notice this slight 
error? Of course, the spelling of a word in this part of the 
display has no effect on the operation of the program. 
Nevertheless, it is good programming practice to make 
the display as accurate and correct as possible. Also, in 
some cases, a program compares your typed input to 
words it already has listed internally. A spelling error will 
result in either a mistaken meaningas in this case, or total 
noncomprehension of your input, such as when you mis- 
type a command keyword in BASIC. In the latter case, 
BASIC will simply inform you of a “Syntax Error in Line 
XXXX°” and stop. Identifying and correcting the error is 


up to you, the programmer. 
When you compare the operation of your program 


with that of FINAL LOAN, you will find that, for small 
numbers, FINAL LOAN does not place the numbers 
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exactly centered under their headings in the display. This 
is because FINAL LOAN is set up for larger loans, such 
as home mortgages, or at least rather expensive cars. 
Thus, the headings are centered over the total allocated 
space for each number, rather than over the smaller test 
numbers that you would use for checking. Try a $20,000 
or $30,000 loan at 10% to 15% interest for a 20 to 30 year 
period, and you may be surprised at how much interest 
gets paid on such a loan. With numbers like these, the 
numbers will be better centered under the headings as 
well. 

The FINAL LOAN program on the enclosed disk is not 
the most complete program possible; there are a number 
of other functions that might be added to it. For example, 
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you might want the program to add and display the 
interest payments for each year for tax deduction pur- 
poses. The printout could also include this display func- 
tion. In addition, you might want to separate each year’s 
payments from the next year’s payments by some blank 
lines, and possibly page the printer to avoid printing over 
the perforations in the paper. 

As time goes on, you will probably think of other 
improvements you would like to add to the pro- 
gram. This is the “Update” phase of programming, 
which effectively continues for as long as the pro- 
gram is in use. Feel free to modify the program at 
any time, in any way you wish. This is your pro- 
gram, to be adjusted to fit your individual wishes 
and needs. 


Sector 2: The CHECKBOOK Program 


To check the operation of the initialization section and 
the menu of the CHECKBOOK program, turn on your 
computer, place your program disk into drive 8, and type 
in the commands: 


LOAD “CHECKBOOk”,8<return> 
RUN<return> 


The first thing the program will do is request today’s date. 
Go ahead and type in the correct date in the format 
requested. For example, January 1, 1987 would be typed 
in as 01/01/87. If you make an error, you can press the 
INST/DEL key to delete the last character so that you 
can enter it again. Be sure to press the <return> key 


when the date is correct. Then, answer “y” to the next 
question and press <return>. 
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OOPS! The next thing we see is a Syntax Error in line 
210. To see this line, type LIST 210<return>. Checking 
back with Figure 4-3, we find that this is indeed what we 
saw there. It looks OK at first glance; colons are correctly 
used to separate the individual variable assignments. 
Each variable name is only 2 characters long, and BASIC 
would permit longer names if desired (it would only 
remember the first two letters, however). Nevertheless, 
BASIC clearly does not like one of these assignments for 
some reason. 

To find out which one, start printing out the values of 
the variables. Any variable which has not yet been 
assigned will have a value of 0. If we check both ends of 
line 210, we find that CN is indeed 1 and CD = 5. How- 
ever, both CF and BA are 0. Therefore, BASIC didn’t get 
this far in the line. As we continue to check variables, we 
find that TX = 0, but ST = 4. 

But we assigned a value of 55 to ST. What happened? 
As it turns out, we inadvertantly used a reserved key- 
word as a variable name. ST is a status code, which can 
be used among other things to check for the end of a file 
you are reading from disk. We will learn later how we can 
use this code, but in the meantime we will have to change 
the name of variable ST. 

If line 210 is still visible on your screen, use the CRSR 
keys (to the right of the right-hand SHIFT key) to move 
the cursor up to line 210. You will need to use the SHIFT 
key as well in order to move the cursor up or to the left. 
Pressing the unshifted CRSR keys will move the cursor 
down or to the right. 

If line 210 has been scrolled off of your screen, LIST 
this line again before using the cursor keys. 

Now, use the CRSR keys to place the blinking cursor 
over the T in the variable name ST. It will be in lower case 
at this point, but that is not a problem; any change you 
make should also be lower case. Type the letter “a” over 
the “t.” This will change the “st” to “sa.” Then press 
<return> to actually enter this change into the program. 
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Now, type RUN<return> and see what happens. We 
make it past line 210 now, but get a syntax error in line 
420. Now what? LIST line 420, and we see that there is a 
comma missing in the GET statement. This command 
should read: get#2,n$ to work properly. Also, if we look 
back at Figure 4-6, we will find that the same comma is 
also missing from lines 440 and 460. Therefore, when you 
have inserted the comma in line 420 and pressed 
<return>, LIST and correct lines 440 and 460 as well. 

This time when you RUN the program, you should not 
receive any error messages. After answering the ques- 
tions, you will get the menu. Try entering numbers from 1 
through 5. Does the program correctly return to the 
menu? (Remember that we don’t have any instructions in 
these routines as yet.) What happens if you select option 
6? 

Before doing anything else, save your corrections to 
this program with the following command: 


SAVE “CHECKBOOK1”,8<return> 


Then, check the disk directory by typing in the 
command: 


LOAD “$”,8<return> 


At this point, you should find the name REGISTER 
listed as a REL file. But we wanted the year to appear as 
part of the filename. Looking back at line 220 (in Figure 
4-3), we find the reason why: another typographical error 
in the program. Here, we used the variable name Y$ 
instead of YR$. You can correct this error next time you 
work on this program. 
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There is one other problem you may have noticed: the 
program did not warn us that this was a new file, and it 
should have done so. Therefore, it also did not request 
the initial information. You will find that the file does have 
two blocks allocated to it, but the basic information is not 
there. 


Sector 3: The PHONEBOOK Program 


The PHONEBOOK program is similar to CHECK- 
BOOK, and is at the same stage of development. To run 
an initial check of its operation, type in the commands: 


LOAD “PHONEBOOK”,8<return> 
RUN<return> 
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Now, run through the same checkout that you per- 
formed for CHECKBOOK. Correct any syntax errors 
you may find, and write the corrected program back to 
disk. Also look for logical errors or strange-looking out- 
puts. Correct errors of this type as well. 

As with CHECKBOOK, we have a number of menu 
options listed, but they don’t do anything yet. Rather, no 
matter which of the main menu options you select, con- 
trol falls through to a GOTO instruction which bounces 
us right back to the menu. However, you can check on 
the correct initialization of the data file and on the correct 
closing of the files when you exit the program. 

With PHONEBOOK, there is no initial data required, 
so the program should not request any particular starting 
data. However, it should still recognize a new file and 
make sure that this is what is wanted. 

With both PHONEBOOK and CHECKBOOK, the 
response to illegal menu options should be the same. 
Invalid numbers should be erased from the screen anda 
valid input requested. Attempts to enter a letter or other 
character will normally result ina REDO FROM START 
error message and a repeat of the input request. Either 
way, the computer will not accept invalid inputs, but will 
correctly handle valid inputs. 


Sector 4: Practice Projects for Next Time 


We have just barely begun the development of the 
CHECKBOOK and PHONEBOOK programs. In your 
next module, we will expand them further. In the mean- 
time, get some practice using your computer by design- 
ing video display layouts for both of these programs. 
Assign line numbers in the 7000s for these display rou- 
tines, and be sure to allow sufficient space on the screen 
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for each entry. You may wish to use our suggested 
layouts as a guide, or design your own. 


Do not attempt to fill in actual names, addresses, 
check numbers, or any other data. Rather, design a 
blank display format with lines and box titles in place. The 
programs, when complete, will fill in the appropriate data 
when needed. 

To draw the layouts, you will need to freely use the 
CRSR keys and the graphics characters. To allow upper 
and lower-case letters, limit your graphics characters to 
those produced with the C= key, and to SHIFT (-) and 
SHIFT *. You will find that these characters all fit togther 
nicely for drawing appropriate boxes. 

As you develop your display, you may find it desirable 
to have the computer complete the display and then stop 
without saying READY or scrolling the display. You can 
accomplish this by placing the line: 


7999 GOTO 7999 
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into your program. This will cause BASIC to wait at line 
7999 until you press the RUN/STOP kev. Also, you can 
bypass most of the program and run just your display 
routine by typing in the command: 


GOTO 7000<return> 


and making line 7000 the first line of your routine. 

Go ahead and design appropriate displays for both of 
these programs, and see if you can find a way to deter- 
mine whether or not a data file has been newly created 
and therefore uninitialized. (HINT: look at the first field in 
the first record, and see if the contents are appropriate 
for the file). In your next module, we will include practical 
display routines and we will explore their operation. In 
addition, we will continue the development of both of 
these programs. 
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